Implement max_events per run limit#2986
Conversation
🦋 Changeset detectedLatest commit: f70fea4 The changes in this PR will be included in the next version bump. This PR includes changesets to release 21 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Workflow Benchmarkscommit Backend:
📜 Previous results (8)f70fea4Tue, 21 Jul 2026 18:44:53 GMT · run logs
6d2ded2Tue, 21 Jul 2026 04:23:07 GMT · run logs
3a9ff12Tue, 21 Jul 2026 01:06:57 GMT · run logs
3f073daMon, 20 Jul 2026 20:27:41 GMT · run logs
8d92b85Mon, 20 Jul 2026 19:32:09 GMT · run logs
5062c00Mon, 20 Jul 2026 18:46:24 GMT · run logs
310f227Fri, 17 Jul 2026 19:14:49 GMT · run logs
330a548Fri, 17 Jul 2026 16:29:55 GMT · run logs
Best/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120 All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor ( Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the |
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
4d4aefc to
d4ddf7e
Compare
d4ddf7e to
330a548
Compare
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
|
Made change to use server provided limit. |
VaguelySerious
left a comment
VaguelySerious
left a comment
There was a problem hiding this comment.
Let's wait with merge until other PRs merge first
|
You must have Developer access to commit code to Vercel Labs on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes. Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles |
|
Backport PR opened against |
2 participants
Summary
Enforces the published per-run events limit, which was previously not enforced. The server supplies the limit on the
run_startedresponse (separate change); once a run's event log reaches it, the runtime throwsMaxEventsExceededErrorat the top of the replay loop, and the existing terminal-error path records it asrun_failedwith a newMAX_EVENTS_EXCEEDEDcode — instead of letting a runaway workflow (e.g. an unbounded step loop) grow the event log without bound.runWorkflowschedules more work; deterministic, so it fails without retry/redelivery and is attributed to user code.WORKFLOW_MAX_EVENTS).Testing
classify-error.test.ts—MaxEventsExceededErrorclassifies asMAX_EVENTS_EXCEEDED.describe-error.test.ts— user attribution + hint for the code.world-testingE2E — a runaway workflow fails withMAX_EVENTS_EXCEEDEDvia the in-process Local World (WORKFLOW_MAX_EVENTS=10, turbo disabled), no Docker.Pairs with the server change: vercel/workflow-server#638